<html>
<head>

<title>Managing Project Source Code</title>

</head>
<body>
<span class="HEADER">Managing project source code</span>
<p>
<span class="PlainText"><b>Project help for project owner administration: Index</b>
<p>

<ul>
<dl>
<dt><a href="ProjectOwnerAdmin.html">Project owner administration</a>
	<dd><a href="ProjectOwnerEdit.html">Editing and maintaining the Project Home page</a>
	<dd><a href="ProjectOwnerNews.html">Managing project site news</a>
	<dd><a href="ProjectOwnerFiles.html">Managing project files</a>
	<dd><a href="ProjectOwnerMembers.html">Adding project members and approving roles</a>
	<dd><a href="ProjectOwnerMailingLists.html">Configuring and managing project mailing lists</a>
	<dd><a href="ProjectOwnerDocuments.html">Managing project documentation</a>
	<dd><b>You are here: Managing project source code
		<ul>
		<li><a href="#gettingstarted">Getting started</a>
		<li><a href="#siteadmincvs">About CVS repository tasks</a>
		<li><a href="#considerations">A few initial considerations for project owners</a>
		<li><a href="#cvspermissions">Managing CVS permissions</a>
		</ul></b>
	<dd><a href="ProjectOwnerIssues.html">Managing project issues and generating reports</a>
<dt><a href="/servlets/HelpTOC">Back to the main Help index</a>
</dl>
</ul>

<p>
<hr noshade size=1>
<a href="gettingstarted"></a><span class="InputHeader">Getting started</span>
<p>
If you are new to CVS, this help guide provides some basic quick reference information for administrative CVS tasks relevant to projects hosted this site. This guide by no means exhaustively documents CVS or the many broader project management issues imputed by versioning control. A wealth of published documentation for CVS exists, both online and in print. The following links lead to general CVS tool documentation elsewhere on this site, and these documents include many authoritative, external CVS resources.
<p>
<b>CVS tool documentation</b>
<dl>
<dt><a href="ddCVS.html">About CVS version control</a>
<dt><a href="ddCVS_cvsglossary.html">A version control glossary</a>
<dt><a href="ddUsingCVS_command-line.html">Using command line CVS</a>
<dt><a href="ddUsingWinCvs.html">UsingWinCvs</a>
</dl>
<p>
<hr noshade size=1>
<a name="siteadmincvs"></a><span class="InputHeader">About CVS repository tasks</span>
<p>
Much of the administrative work involved with setting up your project's source repository is handled "behind the scenes" when your project gains approval. If you are new to CVS, this means that you do not have to start from scratch to set up the CVS repository for your project. 
<p>
The following tasks occur automatically:
<p>
<ul>
<li>Your project's basic repository structure is created with a top-level directory that can be expanded upon by adding subdirectories  as the project evolves. There is also a "/www" directory created for project web content.
<p>
<li>Your project's CVS root (that is, the server where your CVS repository is located) is automatically set to this site's host servers and preconfigured. The instructions in the <b>Project Source</b> page for your project display the exact CVS root needed to log in to the project's source repository. For most projects on this site, the cvsroot will be:
<p> 
<b>:pserver:username@cvs.projectname.thisdomain:/cvs</b>
</ul>
<p>
For CVS experts, this automation means that the CVS administrative module is preconfigured for projects hosted on this site. That includes the following files, listed here for your information:
<p>
<ul>
<li>Modules file
<li>Cvswrappers file
<li>Commit support files
<li>Commitinfo
<li>Verifying log messages
<li>Editinfo
<li>Loginfo
<li>Rcsinfo
<li>Ignoring files via cvsignore
<li>Checkoutlist file
<li>History file
<li>Expansions in administrative files
<p>
</ul>
All CVS repository tasks such as backing up, restoring, moving, or configuring remote repository access are also handled by site administrators. Should your project require  editing CVS administrative files or other repository-level actions, you must contact a site administrator for support.
</ul>
<p>
<hr noshade size=1> 
<a name="considerations"></a><span class="InputHeader">A few initial considerations for project owners</span>
<p>
<span class="PlainText">
<a name="definestructure"></a><b>Starting from scratch</b>
<p>
When your project is completely new or still in infancy, plan the overall directory structure at the front end of project evolution. Although the top level CVS module structure is predetermined, decide how you generally want to organize source files so that you can communicate this to existing and potential contributors. Considering source structure early on enables you to maintain consistency as the project grows, and makes it easier for new contributors to get up to speed.
<p>
A good example of communicating overall project source structure is in the <a href="http://scarab.tigris.org/scarab-design.html#directory" target="_new">design document for the scarab open source project</a> which uses a graphic depiction. CVSWeb source browsing, provided with all projects hosted on this site, also allows users to explore your project's source structure.
<p>

<a name="postrcsissues"></a><b>Version control project management issues</b>

<p>
As the project owner, you are likely to deal with developers who are grappling with the differences between RCS and CVS. Here are some key differences to clarify:
<p>
<ul>
<li>One of the central principals in RCS is file locking, which prevents other developers from checking out or modifying a file when someone else has checked it out. The benefit of file locking is that developers never have to deal with conflicting modifications within files. RCS controls versioning by only allowing files to be modified by one person at a time. Therefore, the drawback to RCS is: no one can commit changes to a file while another developer has it checked out.
<p>
<li>The central tenant of CVS is ability for developers to concurrently check out, modify, and commit files, which greatly benefits projects with developers participating remotely. CVS merges everyone's changes in a central repository, but the tradeoff is developers on your project will inevitably deal with merge conflicts in files. The only way to resolve such conflicts is to edit the file, choosing which changes to keep and which to delete, before it can be committed.
</ul>
<p>
<hr noshade size=1>
<a name="cvspermissions"></a><span class="INPUTHEADER">Managing CVS permissions</span>
<p>
CVS read-access to your project's source code for site users is determined by whether your project is licensed open source or proprietary. Open source projects allow source file read access for any site user by default, whether or not they are project members. Proprietary project pages are not publicly viewable, so source code access is restricted to project members.
<p>
In both open source and proprietary projects, however, you as the Project Owner determine which project members will gain CVS write-access permissions through the roles you grant to them.

<p>
Observers, that is, users you have approved for project membership but who are not actually contributing source code to the project, have read-access but <i>not</i> write-access to your project's source repository . They can check out, view, compare revisions, and update source files, but they cannot contribute modified files or new files to the source repository.
<p>
All other project membership roles automatically confer cvs write-access to project members. This includes the ability to:
<ul>
<li>commit changes/patches
<li>add new files
<li>import files
<li>remove files
<li>check file status
<li>tag and branch files
</ul>
<p>

<p>
Read-write permissions associated with individual files are administered separately from CVS. Note that these permissions cannot be altered for a file once it is checked into the project's CVS repository.
<p>

<hr noshade size=1>
<a href="ProjectOwnerAdmin.html">Back to Project Owner Administration help</a><br>
<a href="/servlets/HelpTOC">Back to main Help index</a></p>

</span>
</body>
</html>
